update

comment

Merge branch 'master' of ssh://git-annex.branchable.com

windows permissions fix

Windows: Fix permission denied error when dropping files that have the
readonly attribute set.

Files coming from a special remote may have had write permission removed
from them. The directory special remote does that. And there are
probably others. So rather than fixing it on the special remote side,
made moveAnnex, on Windows, add back the write bit. This apparently
removes the readonly attribute. See Remote.Directory.removeDirGeneric
which already did the same on windows to allow removing files from the
directory special remote.

The reason that cleanObjectLoc also calls allowWrite is to handle
situations where files have already gotten into git-annex repositories on
Windows with the write bit set. Eg, an older git-annex put them there.
Or perhaps the git-annex repository was populated on some other OS.

Added a comment

close

git-remote-annex enableremote to support readonly webdav

* Allow enableremote of an existing webdav special remote that has
  read-only access.
* git-remote-annex: Use enableremote rather than initremote.

same bug

tag INM7

based on mih filing or commenting on things and/or on
git-remote-annex being used

close, behaving as documented

comment

comment

comment

Fix installation on Android

Unfortunately, commit ce95cac19501bfbffd610203083510888a6b9646 broke
android installation way back in May of last year.

remove multiple dup comments

comment

comment

close, not a bug

mrisse posted a comment earlier explaining the user's confusion to them

retitle

comment

Merge branch 'master' of ssh://git-annex.branchable.com

remove empty comment

reponse

todo from forum post

Added a comment

initial idea on `git annex init` hooks

report on the main repo being offline

removed

Added a comment

Added a comment

Added a comment

removed

encfs testing issue on v10 locked

Added a comment: may be %dotgit?

Added a comment: may be %dotgit?

Merge branch 'master' of ssh://git-annex.branchable.com

forgot to add this comment earlier

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

initial report on encfs and per-repository ssh caching

initial report on encfs and per-repository ssh caching

initial report on encfs and per-repository ssh caching

Added a comment: Same bug

Added a comment: Same bug

Added a comment

Added a comment

Added a comment

Added a comment

VURL verifyKeyContent True when there are no recorded equivkeys

Avoid verification error when addurl --verifiable is used with an url
claimed by a special remote other than the web.

log: Support --key, as well as --branch and --unused

--all remains a special case, since it is more efficient and displays in a
nicer order.

Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project

comment

ssh exit status 255 is a connection problem

Previously, when the git config was unable to be read from a ssh remote,
it would try to git fetch from it to determine if the remote was
otherwise accessible. That was unnessary work, since exit status 255
indicates a connection problem.

As well as avoiding the extra work of the fetch, this also improves
things when a ssh remote cannot be connected to due to a problem with
the git-annex ssh control socket. In that situation, ssh will also exit 255.
Before, the git fetch was tried in that situation, and would succeed, since
it does not use the git-annex ssh control socket. git-annex would conclude
that git-annex-shell was not installed on the remote, which could be wrong.

I suppose it also used to be possible for the user to need to enter a
ssh password on each connection to the remote. If they entered the wrong
password for the git-annex-shell call, but then the right password for
the git fetch, it would also incorrectly set annex-ignore, and that
situation is also now fixed.

comment

comment

improve man page and comment

comment

add news item for git-annex 10.20250102

releasing package git-annex version 10.20250102

prep for release tomorrow and copyright year update

Merge branch 'master' of ssh://git-annex.branchable.com

remove i386ancient and need at least debian stable to build

* Removed the i386ancient standalone tarball build for linux, which
  was increasingly unable to support new git-annex features.
* Removed support for building with ghc older than 9.0.2,
  and with older versions of haskell libraries than are in current Debian
  stable.
* stack.yaml: Update to lts-23.2.

Note that i386ancient was targeting linux 2.6.32, which has been EOL for
over 9 years now. Any old system still using such a kernel is certainly highly
insecure. And I suspect i386ancient had its own insecurities due to haskell
libraries and C libraries not having been updated.

move old fixed datalad/dandi/repronim bugs to the project pages

As done previously in 2023 in commit bcc69f07e81c058eb5d01f4d34c550c49f0631fb

Commands used:

    for f in $(git grep -l '\[\[!tag projects/dandi\]\]'); do if grep -q 'done\]\]' "$f"; then git mv "$f" ../projects/dandi/bugs-done; g=$(echo "$f" | sed 's/.mdwn//'); if [ -d "$g" ]; then git mv "$g" ../projects/dandi/bugs-done; fi; fi; done
    for f in $(git grep -l '\[\[!tag projects/repronim\]\]'); do if grep -q 'done\]\]' "$f"; then git mv "$f" ../projects/repronim/bugs-done; g=$(echo "$f" | sed 's/.mdwn//'); if [ -d "$g" ]; then git mv "$g" ../projects/repronim/bugs-done; fi; fi; done
    for f in $(git grep -l '\[\[!tag projects/datalad\]\]'); do if grep -q 'done\]\]' "$f"; then git mv "$f" ../projects/datalad/bugs-done; g=$(echo "$f" | sed 's/.mdwn//'); if [ -d "$g" ]; then git mv "$g" ../projects/datalad/bugs-done; fi; fi; done

remove old closed bugs and todo items to speed up wiki updates and reduce size

Remove closed bugs and todos that were last edited or commented before 2024.

Except for ones tagged projects/* since projects like datalad want to keep
around records of old deleted bugs longer.

Command line used:

for f in $(grep -l '|done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2024 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2024 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done
for f in $(grep -l '\[\[done\]\]' -- ./*.mdwn); do if ! grep -q "projects/" "$f"; then d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2024 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2024 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; fi; done

Added a comment: Update: rename in separate commits

Added a comment: ViFM Plugin Which Partially Solves The Issue

Added a comment: Workaround for WSL2 on Windows

Added a comment

Added a comment: update 4: union is correct

Added a comment: update 3: strange union behavior

Added a comment: update: unset directory is cool feature, but not always work

Added a comment: unset directory is cool feature, but not always work

Merge branch 'master' of ssh://git-annex.branchable.com

annex.addunlocked support for tree imports

Honor annex.addunlocked configuration when importing a tree from a special
remote.

Note, in a --no-content import, the object file will not be populated
(usually) and so expressions that match on mime type will not match. Tested
this and it works ok, the file just ends up locked. Updated docs for the
mime expressions to mention that they can't match when the file is present

Note that in Command.Sync.pullThirdPartyPopulated, recordImportTree is
called without a AddUnlockedMatcher. Since the tree generated here is not
exposed to the user and does not contain usual filenames, there is no need
of the overhead of checking it.

comment and close

close since --include works

Added a comment: Sync git-annex metadata subset with S3 metadata.

comments

Added a comment: thank you!

fix comment display

Merge branch 'master' of ssh://git-annex.branchable.com

update

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment